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Abstract 


This memo contains a table of commonly occurring headers in headings 
of e-mail messages. The document compiles information from other RFCs 


such as RFC 822, 
RFC 1766, 


RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, 


RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring 


headers which are not defined in RFCs are also included. For each 


header, 


the memo gives a short description and a reference to the RFC 


in which the header is defined. 
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1. Introduction 


Many different Internet standards and RFCs define headers which may 
occur on Internet Mail Messages and Usenet News Articles. The 
intention of this document is to list all such headers in one 
document as an aid to people developing message systems or interested 
in Internet Mail standards. 


The document contains all headers which the author has found in the 
following Internet standards: , RFC 822 [2], RFC 1036 [3], RFC 1123 
[5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], RFC 1766 [12], RFC 
1806 [14], RFC 1864[17] and RFC 1911[20]. Note in particular that 
heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 
[16]) are not included. PEM and MOSS headers only appear inside the 
body of a message, and thus are not headers in the RFC 822 sense. 
Mail attributes in envelopes, i.e. attributes controlling the message 
transport mechanism between mail and news servers, are not included. 
This means that attributes from SMTP [1], UUCP [18] and NNTP [15] are 
mainly not covered either. Headings used only in HTTP [19] are not 
included yet, but may be included in future version of this memo. A 
few additional headers which often can be found in e-mail headings 
but are not part of any Internet standard are also included. 


For each header, the document gives a short description anda 
reference to the Internet standard or RFC, in which they are defined. 


The header names given here are spelled the same way as when they are 
actually used. This is usually American but sometimes English 
spelling. One header in particular, "Organisation/Organization", 
occurs in e-mail headers sometimes with the English and other times 
with the American spelling. 


The following words are used in this memo with the meaning specified 
below: 


heading Formatted text at the top of a message, ended by a 
blank line 


header = heading One field in the heading, beginning with a field 
field name, colon, and followed by the field value(s) 
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It is my intention to continue updating this document after its 
publication as an RFC. The latest version, which may be more up-to- 
date (but also less fully checked out) will be kept available for 
downloading from URL 

http://www.dsv.su.se/~ jpalme/ietf-mail-attributes.pdf. 


Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted 
headers which should be included in this memo but are not. 


2. Use of gatewaying headers 


RFC 1327 defines a number of new headers in Internet mail, which are 
defined to map headers which X.400 has but which were previously not 
standardized in Internet mail. The fact that a header occurs in RFC 
1327 indicates that it is recommended for use in gatewaying messages 
between X.400 and Internet mail, but does not mean that the header is 
recommended for messages wholly within Internet mail. Some of these 
headers may eventually see widespread implementation and use in 
Internet mail, but at the time of this writing (1996) they are not 
widely implemented or used. 


Headers defined only in RFC 1036 for use in Usenet News sometimes 
appear in mail messages, either because the messages have been 
gatewayed from Usenet News to e-mail, or because the messages were 
written in combined clients supporting both e-mail and Usenet News in 
the same client. These headers are not standardized for use in 
Internet e-mail and should be handled with caution by e-mail agents. 


3. Table of headers 
3.1 Phrases used in the tables 


"not for general Used to mark headers which are defined in RFC 

usage" 1327 for use in messages from or to Internet 
mail/X.400 gateways. These headers have not 
been standardized for general usage in the 
exchange of messages between Internet mail- 
based systems. 
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"not standardized 
for use in e-mail" 


"non-standard" 


"discouraged" 


"controversial" 


"experimental" 
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Used to mark headers defined only in RFC 1036 
for use in Usenet News. These headers have no 
standard meaning when appearing in e-mail, 
some of them may even be used in different 
ways by different software. When appearing in 
e-mail, they should be handled with caution. 
Note that RFC 1036, although generally used as 
a de-facto standard for Usenet News, is not an 
official IETF standard or even on the IETF 
standards track. 


This header is not specified in any of 
referenced RFCs which define Internet 
protocols, including Internet Standards, draft 
standards or proposed standards. The header 
appears here because it often appears in e- 
mail or Usenet News. Usage of these headers is 
not in general recommended. Some header 
proposed in ongoing IETF standards development 
work, but not yet accepted, are also marked in 
this way. 


This header, which is non-standard, is known 
to create problems and should not be 
generated. Handling of such headers in 
incoming mail should be done with great 
caution. 


The meaning and usage of this header is 
controversial, i.e. different implementors 
have chosen to implement the header in 
different ways. Because of this, such headers 
should be handled with caution and 
understanding of the different possible 
interpretations. 


This header is used for newly defined headers, 
which are to be tried out before entering the 
IETF standards track. These should only be 
used if both communicating parties agree on 
using them. In practice, some experimental 
protocols become de-facto-standards before 
they are made into IETF standards. 
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3.2 Trace information 


Used to convey the information 
from the MAIL FROM envelope 
attribute in final delivery, when 
the message leaves the SMTP 
environment in which "MAIL FROM" 
is used. 


Trace of MTAs which a message has 
passed. 


List of MTAs passed. 


Trace of distribution lists 
passed. 


3.3 Format and control information 


An indicator that this message is 
formatted according to the MIME 
standard, and an indication of 
which version of MIME is 
utilized. 


Special Usenet News actions only. 


Special Usenet News actions anda 
normal article at the same time. 


Internet Message Headers 


Return-Path: 


Received: 


Path: 


DL-Expansion- 
History- 
Indication: 


MIME-Version: 


Control: 


Also-Control: 


Which body part types occur in Original- 
this message. Encoded- 
Information- 
Types: 
Informational 


February 1997 


RFC 821, 
REG 11233 52 T3 


RFC 822: 4.3.2, 
RFC 1123: 5.2.8. 


RFC 1036: 2.1.6, 
only in Usenet 
News, not in e- 
mail. 


RFC 1327, not for 
general usage. 


REGEN TS2L 2 3 


RFC 1036: 2.1.6, 
only in Usenet 
News, not in e- 
mail. 


son-of-RFC1036 
[21], non- 
standard, only in 
Usenet News, not 
in e-mail 


RFC 1327, not for 
general usage. 
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Controls whether this message may Alternate- RFC 1327, not for 
be forwarded to alternate Recipient: general usage. 
recipients such as a postmaster 

if delivery is not possible to 

the intended recipient. Default: 


Allowed. 
Whether recipients are to be told Disclose- RFC 1327, not for 
the names of other recipients of Recipients: general usage. 


the same message. This is 
primarily an X.400 facility. In 
X.400, this is an envelope 
attribute and refers to 
disclosure of the envelope 
recipient list. Disclosure of 
other recipients is in Internet 
mail done via the To:, cc: and 
bec: headers. 


Whether a MIME body part is to be Content- RFC 1806, 
shown inline or is an attachment; Disposition: experimental 
can also indicate a suggested 

filename for use when saving an 

attachment to a file. 


3.4 Sender and recipient indication 


Authors or persons taking From: RFC 822: 4.4.1, 

responsibility for the message. REG. 11234 22215= 
16,7. 54337 

Note difference from the "From " RFC 1036 2.1.1 

header (not followed by ":") 

below. 

(1) This header should never From not standardized 

appear in e-mail being sent, and for use in e-mail 


should thus not appear in this 
memo. It is however included, 
since people often ask about it. 
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This header is used in the so- 
called Unix mailbox format, also 
known as Berkely mailbox format 
or the MBOX format. This is a 
format for storing a set of 
messages ina file. A line 
beginning with "From " is used to 
separate successive messages in 
such files. 


This header will thus appear when 
you use a text editor to look at 
a file in the Unix mailbox 
format. Some mailers also use 
this format when printing 
messages on paper. 


The information in this header 
should NOT be used to find an 
address to which replies toa 
message are to be sent. 


(2) Used in Usenet News mail From RFC 976: 2.4 for 
transport, to indicate the path or use in Usenet News 
through which an article has gone >From 


when transferred to a new host. 


Sometimes called "From_" header. 


Name of the moderator of the Approved: RFC 1036: 2.2.11, 
newsgroup to which this article not standardized 
is sent; necessary on an article for use in e-mail. 


sent to a moderated newsgroup to 
allow its distribution to the 
newsgroup members. Also used on 
certain control messages, which 
are only performed if they are 
marked as Approved. 


The person or agent submitting Sender: RFC 822: 4.4.2, 

the message to the network, if REC 11234 5.2.15- 

other than shown by the From: 16, BeeT 

header. 

Primary recipients. To: REC 822! 455.1, 
RFC 1123: 5.2.15- 
Tp Sees eed 
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Secondary, informational cc: RFC 822: 4.5.2, 
recipients. (cc = Carbon Copy) RFC 1123. 5.2.15- 
Ter D3 1% 
Recipients not to be disclosed to bec: RFC 822: 4.5.3, 
other recipients. (bcc = Blind REC .d123 e 3 25L5- 
Carbon Copy). LG) DSS 
Primary recipients, who are For-Handling: Non-standard 


requested to handle the 
information in this message 
or its attachments. 


Primary recipients, who are For-Comment: Non-standard 
requested to comment on the 

information in this message 

or its attachments. 


In Usenet News: group(s) to which Newsgroups: RFC 1036: 2.1.3, 
this article was posted. not standardized 
Some systems provide this header and controversial 
also in e-mail although it is not for use in e-mail. 


standardized there. 


Unfortunately, the header can 
appear in e-mail with two 
different and contradictory 
meanings: 


(a) Indicating the newsgroup 
recipient of an article/message 
sent to both e-mail and Usenet 
News recipients. 


(b) In a personally addressed 
reply to an article in a news- 
group, indicating the newsgroup 
in which this discussion 
originated. 
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Inserted by Sendmail when there 
is no "To:" recipient in the 
original message, listing 
recipients derived from the 
envelope into the message 
heading. This behavior is not 
quite proper, MTAs should not 
modify headings (except inserting 
Received lines), and it can in 
some cases cause Bcc recipients 
to be wrongly divulged to non-Bcc 
recipients. 


Geographical or organizational 
limitation on where this article 


can be distributed. 


Fax number of the originator. 


Phone number of the originator. 


Information about the client 
software of the originator. 


3.5 Response control 


This header is meant to indicate 
where the sender wants replies to 
go. Unfortunately, this is 
ambiguous, since there are 
different kinds of replies, which 
the sender may wish to go to 
different addresses. In 
particular, there are personal 
replies intended for only one 
person, and group replies, 
intended for the whole group of 
people who read the replied-to 
message (often a mailing list, 
anewsgroup name cannot appear 
here because of different syntax, 
see "Followup-To" below.). 


Internet Message Headers 


Apparently- 
To: 


Distribution: 


Fax:, 
Telefax: 


Phone: 


Mail-System-— 
Version:, 
Mailer:, 
Originating- 
Client:, X= 
Mailer, X- 
Newsreader 


Reply-To: 


Informational 


February 1997 


Non-standard, 
discouraged, 
mentioned in 
RFC 1211. 


RFC 1036: 2.2.7, 
not standardized 
for use in e-mail. 


Non-standard. 


Non-standard. 


Non-standard. 


RFC 822: 4.4.3, 
RFC 1036: 2.2.1 
controversial. 
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Some mail systems use this header 
to indicate a better form of the 
e-mail address of the sender. 
Some mailing list expanders puts 
the name of the list in this 
header. These practices are 
controversial. The personal 
opinion of the author of this RFC 
is that this header should be 
avoided except in special cases, 
but this is a personal opinion 
not shared by all specialists in 


the area. 

Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3, 
that future discussions (=follow- not standardized 
up) on an article should go to a for use in e-mail. 


different set of newsgroups than 
the replied-to article. The most 
common usage is when an article 
is posted to several newsgroups, 
and further discussions is to 
take place in only one of them. 


In e-mail, this header may occur 
in a message which is sent to 
both e-mail and Usenet News, to 
show where follow-up in Usenet 
news is wanted. The header does 
not say anything about where 
follow-up in e-mail is to be 
sent. 


Note that the value of this 
header must always be one or more 
newsgroup names, never e-mail 


addresses. 

Address to which notifications Errors-To:, Non-standard, 
are to be sent and a request to Return- discouraged. 
get delivery notifications. Receipt-To: 


Internet standards recommend, 
however, the use of RCPT TO and 
Return-Path, not Errors-To, for 
where delivery notifications are 
to be sent. 
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Whether non-delivery report is 
wanted at delivery error. Default 
is to want such a report. 


Whether a delivery report is 
wanted at successful delivery. 
Default is not to generate such a 
report. 


Indicates whether the content of 
a message is to be returned with 
non-delivery notifications. 


Possible future change of name 
for "Content-Return:" 


3.6 Message identification and referral 


Unique ID of this message. 


Unique ID of one body part of the 
content of a message. 


Base to be used for resolving 
relative URIs within this content 
part. 


URI with which the content of 
this content part might be 
retrievable. 


Reference to message which this 
message is a reply to. 


In e-mail: reference to other 
related messages, in Usenet News: 
reference to replied-to-articles. 


References to other related 
articles in Usenet News. 


Reference to previous message 
being corrected and replaced. 
Compare to "Supersedes:" below. 
This field may in the future be 
replaced with "Supersedes:". 


Internet Message Headers 


Prevent- 
NonDelivery- 
Report: 


Generate- 
Delivery- 
Report: 


Content- 
Return: 


X400-Content-— 
Return: 
headers 


Message-ID: 


Content-ID: 


Content-Base: 


Content- 
Location: 


In-Reply-To: 


References: 


See-Also: 


Obsoletes: 


Informational 


February 1997 


RFC 1327, not for 
general usage. 


RFC 1327, not for 
general usage. 


RFC 1327, not for 
general usage. 


non-standard 


RFC 822: 4.6.1 


RFC 1036: 2.1.5. 


RFC 1521: 6.1. 


Non-standard 


Non-standard 


RFC 822: 4.6.2. 


RFC 822: 4.6.3 
RFC 1036: 2.1.5. 


Son-of-RFC1036 
[21], non-standard 


RFC 1327, not for 
general usage. 
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Commonly used in Usenet News in Supersedes: son-of-RFC1036 
similar ways to the "Obsoletes" [21], non-standard 
header described above. In Usenet 

News, however, Supersedes causes 

a full deletion of the replaced 

article in the server, while 

"Supersedes" and "Obsoletes" in e- 

mail is implemented in the client 

and often does not remove the old 

version of the text. 


Only in Usenet News, similar to Article- son-of-RFC1036 
"Supersedes:" but does not cause Updates: [21], non-standard 
the referenced article to be 

physically deleted. 


Reference to specially important Article- son-of-RFC1036 
articles for a particular Usenet Names: [21], non-standard 
Newsgroup. 


3.7 Other textual headers 


Search keys for data base Keywords: RFC 822: 4.7.1 
retrieval. RFC 1036: 2.2.9. 
Title, heading, subject. Often Subject: RFC 822: 4.7.1 
used as thread indicator for RFC 1036: 2.1.4. 


messages replying to or 
commenting on other messages. 


Comments on a message. Comments: RFC 822: 4.7.2. 
Description of a particular body Content- RFC 1521: 6.2. 
part of a message. Description: 

Organization to which the sender Organization: RFC 1036: 2.2.8, 
of this article belongs. not standardized 


for use in e-mail. 


See Organization above. Organisation: Non-standard. 
Short text describing a longer Summary: RFC 1036: 2.2.10, 
article. Warning: Some mail not standardized 
systems will not display this for use in e-mail, 
text to the recipient. Because of discouraged. 


this, do not use this header for 
text which you want to ensure 
that the recipient gets. 
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A text string which identifies Content- RFC 1327, not for 
the content of a message. Identifier: general usage. 


3.8 Headers containing dates and times 


The time when a message was Delivery- RFC 1327, not for 
delivered to its recipient. Date: general usage. 

In Internet, the date when a Date: RFC 822: 5.1, 
message was written, in X.400, RFC 1123: 5.2.14 
the time a message was submitted. RFC 1036: 2.1.2. 


Some Internet mail systems also 
use the date when the message was 


submitted. 

A suggested expiration date. Can Expires: RFC 1036: 2.2.4, 
be used both to limit the time of not standardized 
an article which is not for use in e-mail. 


meaningful after a certain date, 
and to extend the storage of 
important articles. 


Time at which a message loses its Expiry—Date: RFC 1327, not for 
validity. This field may in the general usage. 
future be replaced by "Expires:". 


Latest time at which a reply is Reply-By: RFC 1327, not for 
requested (not demanded). general usage. 


3.9 Quality information 
Can be "normal", "urgent" or "non- Priority: RFC 1327, not for 


urgent" and can influence general usage. 
transmission speed and delivery. 


Sometimes used as a priority Precedence: Non-standard, 
value which can influence controversial, 
transmission speed and delivery. discouraged. 
Common values are "bulk" and 

"first-class". Other uses is to 


control automatic replies and to 
control return-of-content 
facilities, and to stop mailing 
list loops. 
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A hint from the originator to the Importance: RFC 1327 and 
recipients about how important a RFC 1911, 
message is. Values: High, normal experimental 


or low. Not used to control 
transmission speed. 


How sensitive it is to disclose Sensitivity: RFC 1327 and 
this message to other people than RFC 1911, 
the specified recipients. Values: experimental 


Personal, private, company 
confidential. The absence of this 
header in messages gatewayed from 
X.400 indicates that the message 
is not sensitive. 


Body parts are missing. Incomplete- RFC 1327, not for 
Copy: general usage. 


3.10 Language information 
Can include a code for the Language: RFC 1327, not for 


natural language used in a general usage. 
message, e.g. "en" for English. 


Can include a code for the Content- RFC 1766, proposed 
natural language used in a Language: standard. 
message, e.g. "en" for English. 


3.11 Size information 


Inserted by certain mailers to Content- Non-standard, 
indicate the size in bytes of the Length: discouraged. 
message text. This is part of a 

format some mailers use when 

showing a message to its users, 

and this header should not be 

used when sending a message 

through the net. The use of this 

header in transmission of a 

message can cause several 

robustness and interoperability 

problems. 


Size of the message. Lines: RFC 1036: 2.2.12, 


not standardized 
for use in e-mail. 
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3.12 Conversion control 


The body of this message may not Conversion: RFC 1327, not for 
be converted from one character general usage. 
set to another. Values: 

Prohibited and allowed. 


Non-standard variant of Content- Non-standard. 
Conversion: with the same values. Conversion: 

The body of this message may not Conversion- RFC 1327, not for 
be converted from one character With-Loss: general usage. 


set to another if information 
will be lost. Values: Prohibited 
and allowed. 


3.13 Encoding information 


Format of content (character set Content-Type: RFC 1049, 
etc.) Note that the values for RFC 1123: 5 
this header are defined in RFC 1521: 4. 
different ways in RFC 1049 and in RFC 1766: 4 
MIME (RFC 1521), look for the 

"MIME-version" header to 

understand if Content-Type is to 

be interpreted according to RFC 

1049 or according to MIME. The 

MIME definition should be used in 

generating mail. 


RFC 1766 defines a parameter 
"difference" to this header. 


Information from the SGML entity Content-SGML- non-standard 
declaration corresponding to the Entity: 

entity contained in the body of 

the body part. 


Coding method used in a MIME Content- RFC 1521: 5. 
message body. Transfer- 
Encoding: 


Only used with the value Message-Type: RFC 1327, not for 
"Delivery Report" to indicates general usage. 
that this is a delivery report 

gatewayed from X.400. 
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Used in several different ways by 
different mail systems. Some use 
it for a kind of content-type 
information, some for encoding 
and length information, some for 
a kind of boundary information, 
some in other ways. 


3.14 Resent-headers 


When manually forwarding a 
message, headers referring to the Tõi; 
forwarding, not to the original 
message. Note: MIME specifies 
another way of resending 
messages, using the "Message" 
Content-Type. 


3.15 Security and reliability 


Checksum of content to ensure 
that it has not been modified. 


Used in Usenet News to store Xref: 
information to avoid showing a 

reader the same article twice if 

it was sent to more than one 

newsgroup. Only for local usage 

within one Usenet News server, 

should not be sent between 

servers. 


3.16 Miscellaneous 


Name of file in which a copy of Fees 
this message is stored. 


Has been automatically forwarded. Auto- 


Forwarded: 
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Encoding: 


Resent—-From: 
Resent-— 
Sender:, 
Resent—-From: 
Resent—Date: 
Resent-To:, 
Resent-cc:, 
Resent-bcc:, 
Resent-— 
Message-ID: 


Content-MD5: 


Resent-—Reply- 


r 


r 


r 


February 1997 


RFC 1154, 
RFC 1505, 
experimental. 


RFC 822: C.3.3. 


RFC 1864, proposed 
standard. 


RFC 1036: 2.2.13, 
only in Usenet 


News, not in e- 
mail. 


Non-standard. 


RFC 1327, not for 
general usage. 
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Can be used in Internet mail to Discarded- RFC 1327, not for 
indicate X.400 IPM extensions XxX400-IPMS- general usage. 
which could not be mapped to Extensions: 


Internet mail format. 


Can be used in Internet mail to Discarded- RFC 1327, not for 
indicate X.400 MTS extensions X400-MTS-— general usage. 
which could not be mapped to Extensions: 


Internet mail format. 


This field is used by some mail Status: Non-standard, 
delivery systems to indicate the should never 
status of delivery for this appear in mail in 
message when stored. Common transit. 


values of this field are: 


U message is not downloaded 
and not deleted. 


R message is read or 
downloaded. 

O message is old but not 
deleted. 

D to be deleted. 

N new (a new message also 


sometimes is distinguished 
by not having any "Status:" 
header. 


Combinations of these characters 
can occur, such as "Status: OR" 
to indicate that a message is 
downloaded but not deleted. 
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Appendix A: 
Headers sorted by Internet RFC document in which they appear. 


RFC 822 


bec 

cc 

Comments 
Date 

From 
In-Reply-To 
Keywords 
Message-ID 
Received 
References 
Reply-To 
Resent-— 
Resent-—bcc 
Resent-cc 
Resent—Date 
Resent-From 
Resent-From 
Resent-—Message-ID 
Resent-Reply-To 
Resent-To 
Return-Path 
Sender 
Sender 
Subject 

To 


RFC 976 


"From " (followed by space, not colon (:") 
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RFC 1036 


Approved 
Control 
Distribution 
Expires 
Followup-To 
Lines 
Newsgroups 
Organization 
Path 

Summary 

Xref 


RFC 1049 


Content-Type 


RFC 1327 


Alternate-recipient 
Auto-Forwarded 

Autoforwarded 
Content-Identifier 
Content-—Return 

Conversion 
Conversion-With-Loss 
Delivery-—Date 
Discarded-X400-IPMS-Extensions 
Discarded-X400-MTS-Extensions 
Disclose-Recipients 
DL-Expansion—-History 
Expiry—Date 
Generate-Delivery-—Report 
Importance 

Incomplete-Copy 

Language 

Message-Type Delivery 
Obsoletes 
Original-Encoded-Information-Types 
Prevent—NonDelivery-—Report 
Priority 

Reply-By 

Report 

Sensitivity 
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RFC 1505 


Encoding 


RFC 1521 


Content—Description 
Content-ID 
Content-Transfer-Encoding 
Content-Type 

MIME-Version 


RFC 1806 


Content-—Disposition 


RFC 1864 


Content-—-MD5 


RFC 1911 


Importance 
Sensitivity 


son-of-RFC1036 [21] 


Also-Control 
Article-Names 
Article-Updates 
See-Also 
Supersedes 
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Not Internet standard 


Apparently-to 
Content-—Base 
Content-Length 
Content-Location 
Content-SGML-Entity 
Encoding 

Errors-To 
Return-Receipt-—To 
Fax 

"From " (not followed by ":") 
Telefax 

Fcc 

For-Comment 
For-Handling 
Mail-System-Version 
Mailer 

Organisation 
Originating-Client 
Phone 

Status 

Supersedes 
X400-Content-—Return 
X-Mailer 
X-Newsreader 
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Appendix B: 


Internet Message Headers 


Alphabetical index 


Section Heading-header 


WWWW WWW WwW WwW 


WWWWWWW WWW WWW WW WW WwW WwW Ww 


WW w 


WWW WwW 


Palme 


Also-Control 
Alternate-Recipient 
Apparently-To 

Approved 

Article-Names 
Article-Updates 
Auto-Forwarded 

bcc 

cc 

Client, see Originating-Client 
Comments 

Content-—Base 
Content-Conversion 
Content—Description 
Content-—Disposition 
Content-ID 
Content-Identifier 
Content-Language see also Language 
Content-Length 
Content-Location 
Content-MD5 
Content-—Return 
Content-SGML-Entity 
Content-Transfer-Encoding 
Content-Type 

Control 

Conversion 
Conversion-With-Loss 

Date 

Delivery-—Date 


Delivery-Report, Non-Delivery-Report, 
Description, see Content-—Description 
Discarded-X400-IPMS-Extensions 
Discarded-X400-MTS-Extensions 
Disclose-Recipients 

Disposition, see Content-—Disposition 
Distribution 
DL-Expansion-History-Indication 


Encoding see also Content-Transfer-Encoding 


Errors-To 


Informational 


Delivery-Report, see Generate-Delivery-Report, 


February 1997 


Prevent- 
Content-Type 
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3.8 Expires 
Extension see Discarded-X400-IPMS-Extensions, Discarded- 
X400-MTS-Extensions 


3.4 Fax 
3.16 Fcc 
3°34 Followup-To 


Forwarded, see Auto-Forwarded 


3.4 For-Comment 

3.4 For-Handling 

3.4 From 

334 Generate-Delivery-Report 
History, see DL-Expansion-History-Indication 
ID, see Content-ID and Message-ID 
Identifier, see Content-ID and Message-ID 

33.9 Importance 

3.6 In-Reply-To 

Cs] Incomplete-Copy 

ZST Keywords 

3.10 Language see also Content-Language 
Length see Content-Length 

3L Lines 

324 Mail-System-Version see also X-mailer 

3.4 Mailer 
MD5 see Content-MD5 

3.6 Message-ID 

3.13 Message-Type 

3.33 MIME-Version 

3.4 Newsgroups 
Newsreader, see X-Newsreader 
Obsoletes 
Organisation 
Organization 


Original-Encoded-Information-Types 

Originating-Client 

Path 

Phone 

Precedence 

Prevent-—NonDelivery-Report 

Priority 

Received 

Recipient, see To, cc, bcc, Alternate-Recipient, Disclose- 

Recipient 

References 

Reply-By 

Reply-To, see also In-Reply-To, References 
4 Resent-— 

Return see also Content-Return 
332 Return-Path 


WWWWW WWW WW Ww 
NOP ORBRN SA WAATOD 


WWW W 
row © oOo 
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Return-Receipt-To 

See-Also 

Sender 

Sensitivity 

Status 

Subject 

Summary 

Supersedes 

Telefax 

To 

Transfer-Encoding see Content-Transfer-Encoding 
Type see Content-Type, Message-Type, Original-Encoded- 
Information-Types 

Version, see MIME-Version, X-Mailer 
X400-Content-Return 

X-Mailer see also Mail-System-Version 
X-Newsreader 

5 Xref 


WWWWW WWW WwW Ww 
BR HOAIATRFPOBDOW 
(o>) 


WWW WwW 
PeB SD 
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